캐시 제도의 도입
실시간 랭킹 시스템에서 가장 중요하게 고려한 요소 중 하나는 응답 속도와 반복 계산의 최소화였습니다.
특히 동일한 랭킹 데이터에 대한 조회가 빈번하게 발생하는 구조였기 때문에, 계산 결과를 재사용할 수 있는 캐시 구조를 도입하게 되었습니다.
개요
JumpingBattle 서비스의 규모가 증가함에 따라 전국 랭킹, 매장별 랭킹뿐만 아니라 맵, 난이도, 아이템 여부 등 다양한 조건에 따른 랭킹 조회 기능을 제공하게 되었습니다.
그러나 랭킹 데이터의 특성상 동일한 결과에 대한 조회가 반복적으로 발생하였으며, 요청마다 전체 데이터를 조회하고 정렬하는 방식은 비효율적이라고 판단하였습니다.
특히 실시간 랭킹 시스템에서는 단순 응답 속도뿐만 아니라 동일한 계산의 반복을 줄이고 변경된 데이터를 효율적으로 전달하는 것 역시 중요하였습니다.
이에 따라 계산된 랭킹 결과를 재사용할 수 있는 캐시 구조를 도입하게 되었습니다.
왜 캐시를 사용하였는가
캐시를 도입한 가장 큰 이유는 동일한 랭킹 계산의 반복을 줄이기 위함이었습니다.
랭킹 시스템의 특성상 다수의 사용자가 동일한 데이터를 조회하게 되며, 전국 랭킹이나 매장별 랭킹과 같이 자주 조회되는 데이터는 요청마다 동일한 계산이 반복될 가능성이 높았습니다.
특히 랭킹 데이터는 단순 조회가 아니라 정렬과 가공 과정을 거쳐야 했기 때문에, 요청이 증가할수록 서버의 부담 역시 함께 증가하게 됩니다.
따라서 계산이 완료된 랭킹 결과를 캐시에 저장하고 재사용함으로써 반복적인 연산을 최소화하고 보다 빠른 응답을 제공할 수 있도록 설계하였습니다.
또한 SSE 기반 실시간 구조에서는 변경 사항을 빠르게 전파하는 것이 중요하므로, 매번 전체 데이터를 다시 계산하기보다는 캐시된 결과를 활용하는 편이 운영 효율 측면에서도 유리하다고 판단하였습니다.
랭킹 시스템과 캐시
JumpingBattle의 랭킹 시스템은 단순히 하나의 순위표만 제공하는 구조가 아니었습니다.
사용자는 전국 랭킹과 매장별 랭킹을 조회할 수 있었으며, 맵 종류, 난이도, 아이템 사용 여부 등에 따라 서로 다른 랭킹 결과를 확인할 수 있었습니다.
이러한 구조에서는 동일한 원본 데이터를 기반으로 하더라도 사용자가 조회하는 조건에 따라 서로 다른 정렬 결과가 생성될 수 있습니다.
따라서 요청이 발생할 때마다 전체 데이터를 조회하고 정렬하는 방식보다는, 자주 사용되는 랭킹 결과를 미리 계산하여 캐시에 저장하는 방식을 선택하였습니다.
이를 통해 사용자에게는 보다 빠른 응답을 제공할 수 있었으며, 서버 역시 동일한 계산을 반복 수행하지 않아도 되도록 구성할 수 있었습니다.
또한 실시간 랭킹 구조에서는 새로운 기록이 등록되었을 때 변경된 결과를 빠르게 사용자에게 전달하는 것이 중요하였기 때문에, 캐시는 단순 성능 최적화뿐만 아니라 실시간 데이터 제공을 위한 기반 구조로도 활용되었습니다.
실제 운영환경에서의 기대효과
캐시 구조를 도입함으로써 가장 기대한 효과는 사용자 경험의 개선이었습니다.
랭킹 시스템의 경우 사용자는 자신의 순위뿐만 아니라 전국 랭킹, 매장별 랭킹, 맵별 랭킹 등 다양한 데이터를 반복적으로 조회하게 됩니다.
이 과정에서 매 요청마다 전체 데이터를 조회하고 정렬할 경우 응답 시간이 증가할 수 있으며, 사용자는 로딩 지연을 체감하게 됩니다.
반면 캐시를 활용할 경우 이미 계산된 결과를 재사용할 수 있으므로 보다 빠른 응답을 제공할 수 있으며, 사용자는 랭킹 조회 과정에서 불필요한 대기 시간을 줄일 수 있습니다.
또한 검색 기능 역시 동일한 원본 데이터를 반복적으로 처리하기보다는 캐시된 결과를 기반으로 동작할 수 있기 때문에 보다 안정적인 응답 속도를 기대할 수 있었습니다.
결과적으로 캐시는 단순한 성능 최적화 수단이 아니라, 실시간 랭킹 서비스의 사용자 경험을 개선하기 위한 핵심 구조 중 하나로 판단하였습니다.